1. Field of the Invention
The present invention relates to computer networks and, more specifically, to the application of Quality of Service (QoS) treatments to network traffic flows.
2. Background Information
Computer networks typically comprise a plurality of interconnected entities. An entity may consist of any device, such as a computer or end station, that “sources” (i.e., transmits) or “sinks” (i.e., receives) datagrams (e.g., packets and/or frames). A common type of computer network is a local area network (“LAN”) which typically refers to a privately owned network within a single building or campus. LANs typically employ a data communication protocol (LAN standard), such as Ethernet, FDDI or token ring, that defines the functions performed by the data link and physical layers of a communications architecture (i.e., a protocol stack). In many instances, several LANs may be interconnected by point-to-point links, microwave transceivers, satellite hook-ups, etc. to form a wide area network (“WAN”) or intranet that may span an entire country or continent.
One or more intermediate network devices are often used to couple LANs together and allow the corresponding entities to exchange information. For example, a bridge may be used to provide a “bridging” function between two or more LANs. Alternatively, a switch may be utilized to provide a “switching” or interconnection function for transferring information between a plurality of LANs or end stations. Bridges and switches may operate at various levels of the communication protocol stack. For example, a switch may operate at layer 2 which, in the Open Systems Interconnection (OSI) Reference Model, is called the data link layer and includes the Logical Link Control (LLC) and Media Access Control (MAC) sub-layers. Data frames at the data link layer typically include a header containing the MAC address of the entity sourcing the message, referred to as the source address, and the MAC address of the entity to whom the message is being sent, referred to as the destination address. To perform the switching function, layer 2 switches examine the MAC destination address of each data frame received on a source port. The frame is then switched onto the destination port(s) associated with that MAC destination address.
Other network devices, commonly referred to as routers, may operate at higher communication layers, such as layers 3, 4 or even higher. Layers 3 and 4 of Transmission Control Protocol/Internet Protocol (TCP/IP) networks correspond to the IP and TCP/User Datagram Protocol (UDP) layers, respectively. Data frames at the IP layer also include a header that contains an IP source address and an IP destination address. Routers or layer 3 switches may re-assemble or convert received data frames from one LAN standard (e.g., Ethernet) to another (e.g. token ring). Thus, layer 3.devices are often used to interconnect dissimilar subnetworks. Many equipment manufacturers include both layer 2 switching and layer 3 routing functions in a single device.
Voice over IP (VoIP)
Traditionally, computer networks were used to exchange static files or data, such as text and spreadsheet files, while the Public Switched Telephone Network (PSTN) was used to exchange voice information. Computer networks, however, are increasingly being used to transport “voice” information. Voice over IP (VoIP) typically refers to a group of technologies used to transmit voice information over computer networks. Such networks include a plurality of voice agents that convert voice information from its traditional telephony form to a form suitable for packet transmission. In other words, the voice agent encodes, compresses and encapsulates the voice information into a plurality of data packets. Examples of voice agents include end stations running voice applications, IP telephones, VoIP gateways, certain private branch exchanges (PBXs), etc. A calling party uses a voice agent to initiate a VoIP call. Once the voice information has been converted into packet format, it is carried by the computer network to a second voice agent configured to serve the called party. Voice traffic, unlike static data files or records, is highly sensitive to delay and to lost packets. That is, delays in receiving data packets carrying voice information at the called party's voice agent or the loss of such data packets can seriously degrade the quality of the call. Accordingly, packets carrying voice information must be delivered to the called party with a high probability and in a timely manner.
Computer networks include numerous services and resources for use in forwarding network traffic. For example, different network links, such as Fast Ethernet, Asynchronous Transfer Mode (ATM) channels, SONET links, satellite links, etc., offer different speed and bandwidth capabilities. Particular intermediate devices also include specific resources or services, such as priority queues, filter settings, traffic shapers, queue selection strategies, congestion control algorithms, etc. that affect the rate at which traffic moves through the device and thus across the network. Depending on the selection or allocation of such resources or services, network traffic for different sources and sinks can be forwarded at different speeds or rates, thereby controlling the loss and/or delay experienced by the traffic. To take advantage of these services and resources, individual frames or packets can be marked so that intermediate devices will treat them in a predetermined manner.
More specifically, the Institute of Electrical and Electronics Engineers (IEEE), in an appendix (802.1p) to the 802.1D bridge specification standard, describes additional information that can be loaded into the MAC header of Data Link Layer frames. FIG. 1A is a partial block diagram of a Data Link frame 100 which includes a MAC destination address (DA) field 102, a MAC source address (SA) field 104 and a data field 106. In accordance with the 802.1p standard, a user_priority field 108, among others, is inserted after the MAC SA field 104. The user_priority field 108 may be loaded with a predetermined value (e.g., 0-7) that is associated with a particular treatment. Possible treatments include background, best effort, excellent effort, etc. Network devices examine the user_priority field 108 of received frames 100 and apply the corresponding treatment to the frames. For example, an intermediate device may have a plurality of transmission queues per port each queue having a different priority, and may assign frames to different queues of a destination port on the basis of the frame's user priority value.
FIG. 1B is a partial block diagram of a Network Layer packet 120 corresponding to the Internet Protocol (IP). Packet 120 includes a type_of_service (ToS) field 122, a protocol field 124, an IP source address (SA) field 126, an IP destination address (DA) field 128 and a data field 130. The ToS field 122 is used to specify a particular service to be applied to the packet 120, such as high reliability, fast delivery, accurate delivery, etc. It comprises a number of sub-fields, including a three bit IP precedence (EPP) field and three one bit flags (Delay, Throughput and Reliability). By setting the various flags, a source may indicate which overall service it cares most about (e.g., throughput versus reliability). The protocol field 124 is used to identify the next higher protocol that is to receive the packet. Version 6 of the Internet Protocol (IPv6) similarly defines a traffic class field, which is also intended to be used for defining the type of service to be applied to the corresponding packet.
Recently, a working group of the Internet Engineering Task Force (IETF) developed a specification standard for replacing the ToS field 112 of Network Layer packets 120 with a one octet differentiated services (DS) field 132 that can be loaded with a differentiated services codepoint (DSCP) value. Layer 3 devices that are DS compliant apply a particular per-hop behavior (PHB) to packets based on the value contained in their DS fields 132. Examples of PHBs defined by the IETF include expedited forwarding (EF) and assured forwarding (AF).
FIG. 1C is a partial block diagram of a Transport Layer packet 150. In the TCP/IP Reference Model, the transport layer corresponds to the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP). The transport layer packet 150 preferably includes a source port field 152, a destination port field 154 and a data field 156, among others. Fields 152 and 154 are preferably loaded with the predefined or dynamically agreed-upon TCP or UDP port numbers being utilized by the respective applications of the corresponding network entities. A TCP or UDP packet 150 is typically encapsulated within an IP packet 120 by placing it in the data portion 130 of the IP packet 120. The IP packet 120, in turn, is encapsulated in the data portion 106 of a Data Link frame 100 for transmission across a computer link.
The Resource Reservation Protocol
As set forth above, to support VoIP, packets carrying voice information must typically be delivered within narrow time constraints and with high probability. Although many computer networks have the resources and services to meet the delivery requirements of VoIP, these resources and services must be allocated, preferably in advance, to the correct network traffic. The Resource reSerVation Protocol (RSVP), which is set forth at Request for Comments (RFC) 2205, is a signaling protocol that was developed so that entities (typically referred to as receivers) could reserve bandwidth within their computer networks to receive a desired traffic flow, such as voice information or a multimedia stream, from one or more sourcing entities.
Pursuant to RSVP, sources send RSVP Path messages identifying themselves and indicating the bandwidth needed to receive their programming or content. These messages proceed hop-by-hop through the intermediate network devices of the computer network, making those devices aware of the possibility that a reservation of resources may be required. If a receiver is interested in the programming or content offered by a particular source, it responds with a RSVP Reservation (Resv) message, which travels hop-by-hop back to the source. At each hop, the corresponding intermediate device establishes a session for the receiver and sets aside sufficient resources to provide the requested bandwidth for the desired. traffic flow. If the resources are not available, the reservation is explicitly refused so that the receiver knows it cannot depend on resources being devoted to its traffic. By using RSVP, packets carrying voice information can be accorded the resources and services they need to ensure timely delivery.
In some RSVP implementations, each traffic flow, such as a streaming multimedia flow, a real-time voice flow, a video conference flow, etc., is assigned its own reserved queue for transmission purposes. Each reserved queue, moreover, is given a weight and a selection strategy, such as Weighted Fair Queuing (WFQ), is used to select packets from among the various queues for transmission. Many practical implementations of flow-based queuing, however, do. not always result in real-time voice flows being forwarded at sufficient speeds to avoid a degradation in call quality.
Furthermore, with RSVP, path and reservation state is maintained for each flow. This presents scalability problems as the number of flows increases. Indeed, certain devices, such as core routers, may have to maintain thousands or tens of thousands of RSVP flows. This can severely tax the router's processor and memory resources. The path and reservation states, moreover, must also be periodically refreshed, thereby increasing the number of “overhead” messages that are forwarded through the network.
One solution to the real-time traffic forwarding and scalability problems is to have RSVP interoperate with the PHBs of the Differentiated Services (DiffServ) Model. With this solution, per flow state is offloaded to the edges of one or more DiffServ networks, and packets corresponding to the flow are marked before entering the DiffServ networks with appropriate DSCP. Within the DiffServ networks, the RSVP messages are ignored and RSVP states are not maintained. Instead, packets are provided with the PHB associated with the DSCP value with which they have been marked.
There are, nonetheless, several drawbacks with this approach. For example, the source entity or the edge device must be configured to mark the packets of the traffic flow with the correct DSCP. Each device within the DiffServ networks, moreover, must be configured to recognized the marked traffic and apply the corresponding PHB. Precautions must be taken to ensure that only “approved” or “trusted” entities or devices mark traffic with DSCP values. Otherwise, the network could suffer theft-of-service attacks. Furthermore, packets traversing multiple DiffServ networks that belong to different administrative domains may need to be re-marked, unless the domains can agree upon common marking values.